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Abstract 

A method for programming a bus-compatible electronic motor vehicle controller that is equipped with at least one 
microcomputer to implement its control function and with ROM and RAM in order to accommodate and handle 
applications software required for the control function, and is also equipped with at least one bus protocol chip, the . 
ROM being programmed such that the applications software communicates with a bus via the bus protocol chip and 
via a specific instruction and communications interface forming a first interface of the bus protocol chip. The method 
includes providing a second interface, which is independent of the bus protocol chip, and defining the second interface 
as a further, universal instruction and communications interface. The first and second interfaces are coupled with a 
driver module that is independent of the applications software and adapted to the bus protocol chip and has the 
properties of an adapter. The applications software are matched and aligned exclusively to the second interface with 
respect to the bus communication and the applications software is produced independently of the bus protocol chip. 
The applications software and the driver module are linked to one another by a link process. Program code is obtained 
as a result of the link process. The program, code is stored such that the program code is resident in the ROM. 
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Ein Verfahren zur Programmierung eines busfahigen elek- 
tronischen Kfz-Steuergerates wird beschrieben, Jetztwel- 
ches zur Realisierung seiner Steuerfunktion mit wenigstens 
einem Mikrorechner (und) mit ROM und RAM zur Aufnahme 
bzw. Abwicklung der fur die Steuerfunktion erforderiichen 
Applikationssoftware und des weiteren mit wenigstens 
einem Bus-Protokollchip ausgerustet ist, und wobei die 
Programmierung des ROMs in einer Weise geschieht, daS 
besagte Applikationssoftware uber den wenigstens elnen 
Bus-Protokollchip und insoweit im Sinne einer ersten 
Schnittstelle uber dessen/deren spezifische Instruktions- 
und Kommunikationsoberfiache(n) mit dem Bus kommuni- 
ziert. ErfindungsgemaS wird der wenigstens eine Bus-Proto- 
kollchip gegenuber der Applikationssoftware "verdeckt", 
indem eine zweite, universelle, vom/von Bus-Protokoll- 
chipfs) unabhangige Schnittstelle definiert wird, zwecks 
Koppiung dieser Schnittstelle mit der Instruktions- und 
Kommunikationsoberflache des/der Bus-Protokollchip(s) un- 
abhangig von der Applikationssoftware ein auf den/die 
relevanten Bus-Protokollchip(s) zugeschnittenes Treiber- 
Modul mit Adapteretgenschaften erzeugt wird, die steuerge- 
ratespezifische Applikationssoftware ausschlieSlich auf die 
zweite Schnittstelle abgestimmt und ausgerichtet und inso- 
weit unabhangig.von dem/den Bus-Protokoilchip(s) erzeugt 
wird, die von letzterem(n) unabhangige Applikationssoftwa- 
re und das applikationsunabhangige Treiber-Modul mittels 
eines Unkprozesses miteinander verknupft ... 



folgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 
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Die Erfindung betrifft ein Verfahren zur Program- 
mierung eines busfahigen elektronischen Kf z-Steuerge- 
rates in einem Kraftfahrzeug nach der Gattung des An- 
spruchs 1. 

Der vermehrte Einsatz elektrischer und insbesondere 
elektronisch gesteuerter Aktuatoren, Motoren und Ag- 
gregate in Kraftfahrzeugen macht eine immer umfang- 
reichere Verdrahtung erforderlich. Die steigende An- 
zahl von Kontakten und Kabeln bedingt wachsenden 
Fertigungsaufwand, Platzprobleme innerhalb der Ka- 
rosserie und eine insgesamt sinkende Zuveriassigkeit, 
bei zunehmenden Kosten. Fehlersuchen werden immer 
zeitraubender. 

Urn hier Abhilfe zu schaffen, wurde das CAN (Cont- 
roller Area Network)- Konzept entwickelt. Es handelt 
sich dabei um ein serielles Busnetzwerk mit einem spe- 
ziellen Datenubertragungsprotokoll, in welches alle ent- 
sprechenden Komponenten eingebunden werden und 
welches eine Quasi- Echtzeitanwendung mit sehr hoher 
Betriebssicherheit erlaubt 

Im Rahmen dieses neuen Konzepts werden alle Steu- 
er- und Betriebsgerate, die in einem solchen Busnetz 
betrieben werden sollen, mit entsprechenden Hard- und 
Softwaremitteln ausgestattet, so daB sie sich dem Bus- 
protokoll gemaB verhaiten und ohne gegenseitige Be- 
eintrachtigung angesprochen werden bzw. Daten oder 
Steuerbefehle vorzugsweise im Broadcast- Verfahren 
uber das Netz verbreiten kannen. In der Praxis wird dies 
pro Steuergerat durch einen am Bus liegenden und die- 
sen bedienenden Bus-Protokollchip, im folgenden auch 
CAN-Controller oder kurz CAN -Chip genannt, reali- 
siert, welcher mit dem/den jeweiligen hierfur entspre- 
chend programmierten Mikrorechner/n des Steuerge- 
rates, d. h. mit der spezifischen Applikation, kommuni- 
ziert. 

Die Vielzahl von busrelevanten Steuergeraten in ei- 
nem Fahrzeug und die folgliche Beilieferung von unter- 
schiedlichen Herstellern hat demnach. zur Folge, daB 
vergleichbare Zugriffe bzw. Kommunikationsfunktio- 
nen der jeweils steuergeratespezifischen Applikations- 
software auf den Bus je nach verwendetem CAN-Cont- 
roller von jedem Steuergeratehersteiler separat gel6st 
werden mussen und in der Praxis auch auf jeweils ande- 
re Weise gelGst werden. Dies hat nicht nur einen insge- - 
samt erheblichen Zeitaufwand fur die jeweils individuel- 
le Programmierung zur Folge. Aus je nach Programmie- 
rung unterschiedlichen bzw. streuenden Durchgriffszei- 
ten von der Applikation uber den CAN-Controller auf 
den Bus konnen verdeckte Probleme z. B. beim Echt- 
zeitbetrieb einer groBen Zahl von Steuergeraten unter- 
schiedlicher Hersteller entstehen, auch wenn alle Gera- 
te jeweils fur sich alleine genommen das Bus-Protokoll 
einhaiten. 

Es ist daher Aufgabe der Erfindung, ein Verfahren zu 
schaffen, welches eine einfache, zeitsparende, sichere 
und die vorgenannten Probleme minimierende Pro- 
grammierung. von unterschiedlichsten Kfz-Steuergera- 
ten fur Busbetrieb erlaubt. 

Diese Aufgabe wird durch ein gattungsgemaBes Ver- 
fahren mit den kennzeichnungsgemaBen Merkmalen 
des unabhangigen Patentanspruchs I gelost. 

Das erfindungsgemaBe Verfahren macht den bzw. die 
in einem Kfz-Steuergerat jeweils einzusetzenden Bus- 
Protokoll-Chip/s (CAN-Controller) fur den Program- 
mierer der jeweiligen Applikationssof tware "unsicht- 
bar". Da der bzw. die Bus-Protokollchip/s gegeniiber 



der Applikationssoftware also gewissermaBen "ver- 
deckt" wird/werden, spielt die Art des/der jeweils ver- 
wendeten Bus-Protokoll-Chip/s auch keine Rolle mehr. 
Diese Verdeckung wird dadurch geleistet, daB im Sin- 
5 ne einer Instruktions- und Kommunikationsoberfiache 
eine universelle, von dem/den Bus-Protokollchip/s un- 
abhangige Schnittstelle definiert wird, zwecks Kopp- 
lung dieser Schnittstelle mit der/den Instruktions- und 
Kommunikationsoberflache/n des/der Bus-Protokoll- 
io chip/s unabhangig von der Applikationssoftware ein auf 
den/die relevanten Bus-Protokollchip/s zugeschnittenes 
Treiber-Modul mit den Eigenschaften eines Adapters 
erzeugt wird, die steuergeratespezifische Applikations- 
software bezuglich der Buskommunikation ausschlieB- 
15 lich auf die genannte Schnittstelle abgestimmt und aus- 
gerichtet und insoweit unabhangig von dem/den Bus- 
Protokollchip/s erzeugt wird, die von dem/deri Buspro- 
tokollchip/s unabhangige Applikationssoftware und das 
applikationsunabhangige Treiber-Modul mittels eines 
20 Linkprozesses miteinander verkniipft werden und der 
so erhaltene Programmcbde im ROM des wenigstens 
einen Mikrorechners des Steuergerates resident abge- 
legtwird. 

Die verknupfte Niederlegung des CAN-Controller- 
25 spezifischen Treiber-Moduls zusammen mit der jeweili- 
gen Applikationssoftware in jedem einzelnen von einer 
Vielzahl von Steuergeraten erspart so nicht nur unndti- 
ge' Software-Entwicklungszeit fUr gleichartige oder 
ahnliche kommunikationsschritte bzw. -operationen. 
30 Durch Reduktion der applikationsseitig auszufiihren- 
den Operationen auf nur wenige, einfache, jedoch lei- 
stungsfahige Routinen, die von der Applikation kom- 
mend auf den Bus gerichtet bzw. vom Bus kommend in 
die Applikation gerichtet auszuftihren sind, kann auch 
35 eine sehr hohe Betriebssicherheit und Echtzeit-Vertrag- 
lichkeit vieler Steuergerate in einem CAN-Busnetzwerk 
erreicht werden, zumal entsprechende Treibermodule 
fur unterschiedliche Bus-Protokollchips bzw. CAN- 
Controller jeweils zentral entwickelt, ausgetestet und 
40 verftigbar gemacht werden konnen. 

Weitere Vorteile werden erschlossen, wenn das Trei- 
ber-Modul nach Lehre wenigstens eines der Anspriiche 
2 bis 6 hergestellt wird. Werden z. B. gemaB Lehre des 
Anspruchs 4 wenigstens Netzwerk-Managementfunk- 
45 tionen in einem weiteren Modul zusammengefafit und 
wird dieses weitere Modul analog dem Treiber-Modul 
der Applikationssoftware beigelinkt, kann der Program- 
mierer der Applikationssoftware von Aufrufen, Adres- 
sierungen und/oder Management- Alogorithmen befreit 
so werden, die far das Zusammenwirken im Netz des be- 
treffenden Kfz-Steuergerates mit anderen notwendig 
sind. Diese und weitere Vorteile, die sich bei Anwen- 
durig des erfindungsgemaBen Verfahrens erschlieBen 
lassen, werden im Zuge der nachfolgenden Beschrei- 
55 bung unter Bezugnahme auf die Zeichnung aufgezeigt 
Eszeigen: 

Fig. 1 ein Strukturschema zur Veranschaulichung der 
Einbettung des Treiber-Moduls zwischen Bus-P'roto- 
kollchip und Applikationssoftware; 
6 o Fig. 2 eine schematische Veranschaulichung der 
Adapterfunktion des Treiber-Moduls und seiner CAN- 
chip-spezifischen Austauschbarkeit; 

Fig. 3 eine schematische Veranschaulichung eines 
entsprechenden Treiber-Moduls zur Adaption dreier 
65 CAN-Chips an die Applikation; 

Fig. 4 eine schematische Veranschaulichung der Ab- 
arbeitung einer Sende-Warteschlange; 
Fig. 5 eine Veranschaulichung von Kopierfunktionen 



DE 42 29 931 Al 

3 . 4 

des Treiber-Moduls; Es sind in der Art von Einhullenden eine erste Schnitt- 

Fig. 6 eine schematische Veranschaulichung mehre- .stelle 17, namlich die Instruktions- .und Kommunika- 

rer mit unterschiedlichen GAN-Chips ausgerusteter und tionsoberfiache des CAN-Chip, eine zweite Schnittstel- 

zueinervirtuellenEinheitintegrierterSteuergerate. . le, namlich die erfindungsgemaB zu definierende CAN- 

Im folgenden wird unter dem Kurzbegriff des "CAN- 5 Treiber-Schnittstelle 18 und des weiteren noch eine Ma- 
Chip" immer der hardwaremiBig zu bestuckende Bus- nagement-Schnittstelle 19 und eine der Management- 
Protokollchip verstanden. Ausdrucklich wird darauf Schnittstelie 19 entsprechende und je nach Fullung des 
hingewiesen, daB unter "dem" CAN-Chip auch mehrere Kommunikations-Moduls 13 zu spezifizierende Schnitt- 
. entsprechende Exemplare verstanden werden kdnnen, stelle 19' der Applikation 11 kenntlich gemacht 
die gewissermaBen einen leistungsfahigeren CAN-Chip 10 Funktionselemente des verfahrensgemaB zu erzeu- 
substituieren bzw. implementieren. Des weiteren wird genden Treiber-Moduls werden aus Fig. 2 deutlich. 
unter "Applikation" die Abwicklung der Applikations- Das Treiber-Modul 10A umfaBt u. a., einen logischen 
software, d. h. der spezifischen Betriebs- und System- . Code 14. Dieser Code 14 ubersetzt gewissermaBen den 
software eines jeweils betrachteten Steuerger&tes auf CAN-Chip- typenspezifischen Instruktionscode von der 
seiner (Applikations-) Hardware verstanden, mit der 15 Ebehe der besagten ersten Schnittstelie 17 in ein stan- 
Wirkungder erwtinschten Steuerf unktiori. dardisiertes Instruktionsformat auf der Ebene der be- 

GernaB Fig, 1 kommuniziert die Applikationssoftwa- . sagten CAN-Treiber-Schnittstellen 18, auf welcher die 

re 11 nicht eigenstandig iiber den CAN-Chip 1 mit dem Applikationssoftware 11 zugreift. Der im ROM der Ap- 

Bus 2. Bezuglich des Nachrichtenverkehrs mit letzterem plikation abgelegte logische Code 14 erftillt dabei eine 

.stellt vielmehr das verfahrensgemaB herzustellende 20 Funktion vergleichbar der eines Adapters oder Interfa- 

Treiber-Modul 10 einen intelligenten Adapter dar, iiber ce auf die einfache, aber leistungsfahige Schnittstelie 18 

den jeder kommunikative Zugriff auf den Bus 2 bzw. die mit eigener funktionaler Intelligenz, die einerseits die 

Applikationssoftware 11 zustande kommt Hieraus folgt Applikation — und damit den Applikationsprogram- 

eine entkoppeinde bzw. isolierende Funktion des Trei- . mierer — von elementaren Kommunikationsaufgaben 

ber-Moduls 10 zwischen CAN-Chip 1 bzw. Bus 2 und 25 entlastet und andererseits die korrekte und netzweit 

Applikationssoftware 11. ^ einheitliche Programmierung des bzw. der CAN-Chips 

Die Herstellung der Applikationssoftware kann in der gewahrleistet. 

Regel beim Hersteller bzw. Lieferanten eines Steuerge- Weiter umfaBt das Treiber-Modul 10 ein Datenfeld 

rates geschehen. Die Herstellung des Treiber-Moduls 15, das entweder vollstandig oder iiberwiegend im ROM 

kann beispielsweise durch den Fahrzeughersteller ge- 30 der Steuergeratehardware deponiert wird. Es ist dies 

schehen, der es darin Zulief eranten von busf ahigen Steu- wenigstens eine Initialisierungsstruktur und eine Kom- 

ergeraten zwecks Generation deren Software zur Ver- munikationsstruktur, Initialisierungsobjekte II ..... Iy 

fugung stellt. Auf diese Weise kann ieicht sichergestellt bzw. Kommunikationsobjekten Kl . . . . . Kx umfassend. 

. werden, daB die Herstellung und Austestung des Trei- Dariiber hinaus beansprucht das Treiber-Modul 10A 

ber-Moduls mittels derselben Priifkriterien 1 geschieht, 35 auBerdem noch einen (kleihen) RAM-Bereich, um dort 

die auch in Bus-Priifsystemen in Produktion und Service in einem fltichtigen Datenfeld 16 z. B. Statusinformatio- 

des Fahrzeugherstellers eingesetzt werden. Auf diese nen oder eine Warteschlange zu verwalten oder z. B. 

Weise werden systematische Softwareunvertraglichkei- FunktionsrOckgabewerte zu fuhren. 

ten ausgeschlossen und es konnen lokale Fehler und Die Initialisierungsstruktur enthalt Daten, mit denen 

deren Orsache(n) leicht erkahnt werden. 40 die Register bzw. Speicherzeilen des CAN-Chip in Ab- 

Zwischen Treiber-Modul 10 und Applikationssoftwa- hangigkeit von der aktuell ausgewahlten Initialisie- 

re 11 kann noch ein separat zu erzeugendes Netzwerk- rungsvariante geladen werden. 

management-Modul 12 eingebunden werden., Analog Die Kommunikationsstruktur gliedert sich in Sende- 

dazu kann des weiteren noch ein spezielles Kommuni- , urid Empfangsstruktur, jeweils Sende- bzw. Emfangs- 

kations-Modul 13 erzeugt und zwischen Treiber-Modul 45 Kommunikationsobjekte umfassend. Die Sende- und 

10 und Applikationssoftware 11 eingebunden werden., Empfangsstrukturen enthalten Informationen iiber die 

Jedenfalls verfiigt die Applikation 11 aber immer iiber zu sendenden bzw. zu empfangenden Daten sowie die 

einen freien Zugang 11' zum.Treibermodul 10 iiber be- erforderlichen Zeiger, welche diezu benutzenden Berei- 

sagte CAN-Treiberschnittstelie 18. Unter bestimmten che im RAM des Steuergerates bzw. CAN-Register . 

Voraussetzungen kann es in der Regel allerdings vor- 50 festlegen. 

teilhafter sein, Kommunikationsroutinen in die Applika- Fig. 2 veranschaulicht weiter, daB es fur CAN-Chips 

tionssoftware 11 von Anfang an einzubauen, wie dies 1A, IB, 1C etc. jeweils ein entsprechendes Treiber-Mo- 

z. B. der Veranschaulichung gemaB Fig. 6 zugrunde ge- dul 10A 10B, 10C ... gibt. Unterschiedlichen CAN- 

legt ist. Chips 1 A bis 1C, iiber End- und Empfangsstufen 3 glei- 

Ein besonderes Netzwerkmanagement-Modul 12 55 chermaBen an den CAN-Bus 2 angeschaltet, sind also 

kann z. B. Aufgaben i.Z. mit der Bedienung weiterer entsprechend unterschiedliche Treiber- Module 10 A bis 

Steuergerate am Bus oder der Erm6glichung eines Ein- 10C zugeordnet Entsprechend den unterschiedlichen 

draht-Notbetriebs erfiillen, wenn z. B. eine von zwei Eigenschaften verschiedener CAN-Chips 10A . . . 10C 

elektrischen Busadern Masse- oder Versorgungsspan- variieren jeweils wenigstens der Code 14 und einzelnen 

nungsschluB hat. Ein besonderes Kommunikakations- 60 Datenobjekte im Datenfeld 15 bei entsprechenden Trei- 

Modul 13 kann z. B. diejenigen Teile von Kommunika- ber-Modulen. 

tionsroutinen zusammenfassen, die fur mehrere Steuer- Im Sinne von Fig. 3 kann "der" CAN-Chip 1 auch aus 

gerate identisch sind. Beispielsweise kann es applika- mehreren realen Bus-Protokollbausteinen 1.1, 1.2, 1.3, 

tionsspezifische Handler-Rout inen, oder aber spezielle eta bestehen, die insgesamt wie ein (einheitlicher) Chip 

Kommununikationsfunktionen enthalten, etwa Kopier- 55 zwischen Applikationssoftware 11 und Bus 2 wirken. 

funktionen, wie z. B. die noch weiter unten erwahnte Ohne Beschrankung der Allgemeinsheit realisiert ein 

Pre- und Postcopy- Funktion in Verbindung mit Elemen- . entsprechend aufgebautes Treiber-Modul 10' auch hier 

ten zur Empfangsfilterung. die Treiberschnittstelle 18 und "verbirgf dann eine ent- 
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sprechende Mehrzahl von CAN-Chips gegenuber dem 
Programmierer der Applikationssoftware. 

Allen Treiber-Modulen 10A, 10B, IOC gleich ist je- 
doch eine einheitliche Beschaffenheit der CAN-Treiber- 
schnittstelle 18, so daB der applikationsseitige Funk- 5 
tionsaufruf des Treiber-Moduls stets mit derselben Da- 
tenobjekt-Referenz erfolgen kann, d. h. unabhangig 
vom benutzten CAN-Chip. 

Bei der Herstellung des Moduls wird der logische 
Treiber-Code beispielsweise insgesamt so gebaut, daB 10 
er, in Verbindung mit den vorerwahnten Daten, nach 
der Verkniipfung mit der Applikationssoftware folgen- 
de Funktionen leistet: 



a. Initiaiisierung 



15 



; Vor dem Beginn einer Kommunikation werden die 
CAN-Kommunikationspfade und der CAN-Controller 
initialisiert. Dies geschieht durch einfachen Aufruf der 
Funktion 20 
IiuH(Zeiger auf Initialisierungsobjekt). 

Hierftir werden in dem als Argument des Initialisie- 
rungsaufrufs bezogenen Initialisierungsobjekt alle not- 
wendigen Parameter fiir die CAN-protokollgemaBe 
Chipinitialisierung abgelegt 25 

b. Aussenden von Daten 

Fiir die Aussendung von Daten wird ein Sende-Kom- 
munikationsobjekt definiert, in dem unter anderem ein 30 
die betreffende CAN-Nachricht kennzeichnender Iden- 
tifier und ein Zeiger auf die RAM-Adresse der auszu- 
sendenden Applikationsvariable abgelegt wird. Die 
Aussendung von Daten wird bewirkt durch einfachen 
Auf ruf der Funktion 35 
Transmit(Zeiger auf Sende-Kommunikationsobjekt). 
Dieser Aufruf bewirkt, daB mittels des Kbmmunika- 
tionsobjekts die relevante Applikationsvariable in den 
CAN-Chip oder in den Treiber (narrilich z. B. in eine 
Warteschlange, s. u.) kopiert wird. AnschlieBend erfolgt 40 

. deren Aussendung auf deh Bus vorzugsweise asynchron, 
was bedeutet, daB die, Applikationssoftware nicht auf 
eine Quittung des erfolgreichen Aussendevorganges 
wartet Sie wird jedoch zu einem fruhestmdglichen Zeit- 

. punkt darUber informiert. Auch wird die erfolgreiche 45 
Obernahme der Applikationsvariable in die Verantwor- 
tung des Treiber-Moduls der Applikation angezeigt 



c. Sendeabbruch 



50 



Zwecks Abbruch bzw, Nichtausfahrung eines beretts 
erfolgten Aufrufs zum Versand einer Nachricht ist die 
besohdere Funktion 

Cancel (Zeiger auf Sehde-Kommunikationsobjekt) 
vorgesehen. Ihr Aufruf bewirkt die Stornierung eines 55 
vorausgegangenen Transmit-Aufrufs durch Ldschung 
des Sehdeauftrages im Treiber oder — soweit bereits in 
das Sende-Bufferregister des CAN-Chip eingeschrieben 
und noch nicht versandt — eben dort 



d. Empfang 



60 



Im Gegensatz zu komfortablen CAN-Chips mit eige- 
nem RAM (etwa FULLCAN-Chips) sind einfachere 
CAN-Chips (etwa BASIC AN -Chips) nicht in der Lage, 65 
alle Nachrichten, die iiberhaupt empfangen werden 
kdnnen oder sollen, vollstandig selbst zu filtern. 

Diese einfacheren CAN-Chips verfiigen nur tiber ein 



Register, das zwecks Ladung als "Empfangsfenster" ge- 
dffnet wird, sofern der Identifier einer CAN-Botschaft 
in eine vorbestimmte Maske fallt Die Selektion bzw. 
Akzeptanzpriifung aus einer Vielzahl von aus dieserri 
Register holbaren Daten muB also auBerhalb eines sol- 
chen einfacheren CAN-Chips geschehen. 

Vorzugsweise wird das Treiber- Modul so gebaut, daB 
es auch diese Funktion leistet, indem es den Empfangs- 
betrieb interruptgesteuert abwickelt Dazu wird ftir je- 
den zu empfangenden Nachrichtentyp ein Empfangs- . 
Kommunikationsobjekt definiert In diesem wird u.a. 
der die betreffende CAN-Botschaft kennzeichnender 
Identifier und ein Zeiger auf die Zielvariable im RAM 
der Applikation abgelegt Durch den einfachen Aufruf 
Receive (Zeiger auf Empfangs-Kommunikationsobjekt) 
werden die Empfangsdaten aus dem Empfangs-Buffer- 
register des CAN-Chip in einen fur relevante Empfangs- 
daten vorgesehenen Speicherplatz im RAM der Appli- 
kation (Zielvariable) kopiert Das Treiber-Modul dese- 
lektiert insoweit also alle unerwiinschten Empfangs- 
Kommunikationsobjekte. 

Auf diese Weise wird — unabhangig vom realen 
CAN-Protokollchip — z. B. die Funktion eines komfort- 
ableren CAC-Chip, etwa eines FULLCAN-Chip, substi- 
tuiert, welcher aufgrund AusrUstung mit, einem eigenen 
RAM eine Akzeptanzliste fiir alle iiberhaupt zu empfan- 
genden und in vorbestimmte RAM-Bereiche des Appli- 
kationskontrollers zu schreibenden Nachrichten halten 
und verwalten kann. 

Es wird ersichtlich, daB relevante Identifier nur dem 
Hersteller des Treiber-Moduls bekannt sein mlissen und 
in der ROM-Liste 15 des Treiber-Moduls verzeichnet 
sind, die Applikation bzw. der die Applikationssoftware 
herstellende Programmierer dieselben jedoch nicht zu 
kennen braucht, weil Empfangsdaten, die weiterverar- 
beitet werden sollen, immer nur aus vorbestimmten, 
festliegenden Speicherzellen des Applikations-RAMs 
abgeholt zu werden brauchen. 

e. Precopy und Postcopy 

Urn einer Applikation beziiglich zu empfangender 
Daten die M6glichkeit einer Selektion zu bieten (z. B. 
fur Filterungs- und/oder UberprUfungsfunktionen), 
werden in dem verf ahrensgemaB zu erzeugenden Trei- 
ber-Modul wenigstens zwei weitere Subroutinen "Pre- 
copy" und "Postcopy" eingebaut, welche es der Applika- 
tion erlauben, unmittelbar vor dem Empfang von Daten 
bzw. unmittelbar nach dem Auslesen empf angener Da- 
ten aus dem Ernpfangs-Bufferregister 21 des CAN-Chip 
1 in die Zielvariable (Zielspeicherplatz im RAM der Ap- 
plikation) EinfluB auf die empfangenen Daten zu neh- 
men. Wie diese beiden Funktionen wirken ist in Fig. 5 
veranschaulicht 

Mit 21 ist das Ernpfangs-Bufferregister des am Bus 2 
liegenden CAN-Chip 1 bezeichnet, in welches die Emp- 
fangsbotschaften vom Bus geladen werden. Mit 15 ist 
ein kleiner Ausschnitt aus dem ROM und mit 16 ein 
kleiner Ausschnitt aus dem RAM der Applikation be- 
zeichnet Beispielsweise sind im ROM 15 Speicherberei- 
che 23.1, 23.2, 233, etc. vorgesehen, in welche Identifier, 
hier beispielsweise x, y, und 49, fur Empfangsnachrich- 
ten eingeschrieben sind. Jedem Identifier sind hier bei- 
spielsweise acht weitere Speicherplatze 23.1.1 bis 23.1.8, 
23.2.1 bis 23.2.8, 23.3.1 bis 23.3.8, etc zugeordnet, in 
welche zum jeweiligen Identifier gehdrende Parameter 
abgelegt sind 

Im RAM 16 sind drei verschiedene Speicherplatze 25, 
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27 und 30 hervorgehoben, in welche eine Empfangsbot- 
schaft ablegbar ist Dabei ist angenommen, daB der 
Speicherplatz 25 zur Ablage der Empfangsbotschaft 
zwecks deren unmittelbarer Weiterverarbeitung, der 
Speicherplatz 27 zur Ablage der Empfangsbotschaft 
zwecks einer wie immer gearteten Bearbeitung vor 
Weiterverarbeitung, und der Speicherplatz 30 zur Abla- 
ge einer Kopie der Empfangsbotschaft nach deren Emp- 
fangseinschrieb in das RAM 16 vorgesehen ist. 

Die. Funktion ist folgende. Botschaften werden uber 
den Bus 2 im Broadcast- Verfahren versandt, erreichen 
insoweit also grunds&tziich alle CAN-Chips der einzei- 
nen am Bus liegenden Steuergerate. Soweit es sich hier- 
bei nicht um CAN-Chips mit 100%iger Akzeptanz-Fil- 
terung, also beispielsweise FULLGAN-Chips, handelt, 
erfolgt wenigstens die FOterung bzw. Diskrirnination 
der Empfangsbotschaften vermittels des Treiber-Mo- 
duls auBerhalb des CAN-Chip 1. 1 

Sobald eine beliebige Botschaft im Empfangs-Buffer- 
register 21 eingeladen ist, greift die Applikation per In- 
terrupt-Service-Routine 22.0 auf das ROM 15 zu und 
tiberpriift, beispielsweise durch sukzessives Abfragen 
22.1, 22.2 alle dort in Speicherplatzen 23.1, 23.2, 23.3, etc. 
abgelegten Identifier auf Obereinstimmung mit dem 
Identifier der Empfangsbotschaft ab. 

U.U, wird keine Obereinstimmung festgestellt, was 
bedeutet, daB die Empfangsbotschaft nicht ausgewertet 
wird, weil sie z. B. gar nicht fur das betrachtete Steuer- 
gerat aus einer bestimmten Kategorie von Steuergera- 
,ten, etwa solchen mit einem BASICAN-Chip, bestimmt 
ist. 

Wird jedoch der in das Empfangs-Bufferregister aktu- 
ell eingeladene Empfangs-Identifier, hier angenommen 
"49", beispielsweise im Speicherplatz 23.3 vorgefunden, 
fragt die Interrupt-Service Routine alle nachfolgenden 
Speicherplatze 23.3.1 bis 23.3.8. sukzessive 22.3 nach 
darin enthaltenen Adress-Codierungen fur den RAM- 
Einschrieb besagter Empfangsbotschaft ab. Beispiels- 
weise ist in den Speicherplatz 23.3.1 eine ''0" eingg- 
schrieben. Dies bewirkt den Einschrieb 24 der Botschaft 
im Empfangs-Bufferregister 21 in den Speicherplatz 25 
im RAM 16 der Applikation, dessen Adresse z. B. im 
ROM-Platz 23.3.2 abgelegt ist Ist in den Speicherplatz 
23.3.1 hingegen ein von "0" abweichender Wert — hier 
beispielsweise "101 10" — eingeschrieben, so wird dieser 
Wert als Startadresse einer zwecks Bewertung, Filte- 
rung, eta der Empf arigsdaten vorgesehenen Anwender- 
funktion interpretiert, die mit dieser Adresse im Spei- 
cherplatz 27 des RAMs 16 der Applikation abgeiegt ist 
und der die Botschaft im Empfangs-Bufferregister 21 
unterworfen wird (Precopy), bevor sie weiterverarbei- 
tet (und zu diesem Zwecke dann z. B. in den Speicher- 
platz 25 abgelegt) wird. Hierzu kttnnte die Empfangs- 
botschaft z. B. vorubergehend in einen Zwischenspei- 
cherplatz 28 im RAM 16 geladen werden. Entsprechen- 
de Adressen der RAM- Speicherplatze 27 und 28 kSnnen 
im ROM-Speicherplatz 233.1 mitabgelegt sein. ; 

Ein bestimmter Wert im letzten Speicherplatz 23.3.8 
bewirkt hingegen, daB die zwecks Empfangsverarbei- 
tung bereits ins RAM 16 eingeschriebene Empfangsbot- 
schaft in einen besonderen Speicherplatz 30 des RAMs 
16 kopiert 29 wird (Postcopy), was z. B. fUr ein Steuerge- 
rat wichtig sein kann, das die zeitliche Anderung einer 
MeBgroBe auswertet und insoweit auf die Festhaltung 
jeweils wenigstens eines letzten bzw. zurOckliegenden 
MeBwertes angewiesen ist 

Es kdnnen so im Zuge des Datenempfangs gezielt 
kurze, applikationsspezifische Operationen bezuglich 



. empfangener Daten ausgefiihrt werden, wie z. B. die 
Demultiplexierung eines CAN-Datenpakets in einzelne 
Variable, die Selektion bestimmter Bytes einer Nach- 
richt, Umlenkung. empfangener, aber fehlerhafter Da- 

5 ten, zusatzliche bzw. verscharfte Empf angsfilterung, In- 
terpretation oder KJassifikation oder Entschlusselung 
von Daten vor deren Abspeicherung, etc. 

ErsichtlichermaBen erschlieBen.diese. zwei Routinen 
eine sehr differenzierte Ve'rarbeitbarkeit von Emp- 

io fangsbotschaften. Sie werden durch den einfachen Auf- 
ruf 

Precopy (Zeiger auf Empf angs-Kommunikationsobjekt) 
oder 

•Postcopy (Zeiger auf Empfangs-Kommunikationsob- 
15 jekt) 
aktiviert. 

f. Remote Request Service 

20 Das Treiber-Modul kann auch die Remote-Eigen- 
schaften des CAN-Protokolis unterstiitzen. Die entspre- 
chende Remote Request Service Funktion emuliert bei 
Anwendungen mit CAN-Chips, die keine automatische 
Beantwortung eines Remote Request unterstiitzen, die 

25 immanente Remote Request Funktion von CAN-Chips, 
die ohne Einschrankung das. gesamte CAN-Protokoll 
unterstutzen und autonom abwickeln konnen, etwa 
v FULLCAN-Chips. Dabei kann die Transmit- Funktion 
vermittels eines im CAN-Protokoll designierten Steuer- 

30 Flags Remote-Botschaften auf den Bus aussenden. Emp- 
fangene Remote-Frames werden entweder durch den 
FULLCAN-Chip oder durch das Treiber-Modul bear- 
beitet und beantwortet Die Applikationssoftware 11 
bzw. die Applikation wird hiervon uber eine entspre- 

35 chende Statusinformation unterrichtet, welche in dem 
schon erwahnten Datenfeld 16 abgelegt wird. 

FOr die Bearbeitung von schnell aufeinanderfolgen- 
den Sendeanforderungen und zur Realisierung einer 
Multitaskingfahigkeit des Treiber-Moduls ist es vorteil- 

40 haft, in diesem gemaB Fig. 4 eine Sende-Warteschlange . 
20 zu impiementieren. Deren Verwaltung und Abarbei- 
tung geschieht vorzugsweise asynchron und vom CAN- 
Chip aus interruptgesteuert. Der Programmierer der 
Applikationssoftware ist dann auch bezuglich Versand- 

45 abfolgen ungebunden vom CAN-Chip und braucht ihn 
deshalb riicht zu kennen. 

Neben Anforderungen seitens der Applikation kdn- 
nen in eine solche Warteschlange auch Sendeanforde- 
rungen eines besonderen Netzwerkrnanagement-Mo- 

50 duls 12 geladen werden, welches mehr oder weniger fest 
in die Applikationssoftware 11 eingebunden ist Die Ap- 
plikationssoftware wird jedenfalls durch kommunika- 
tionsobjektbezogene Statusinformation, die in die Sta- 
. tusdatei in das RAM 16 der Applikation geschrieben 

55 wird, uber den jeweiligen Zustand des Sendeauftrages 
aktuell informiert. 

Die Sendewarteschlange bewirkt eine sehr vorteilhaf- 
te zeitliche Entkopplung zwischen der Applikationssoft- 
ware, den CAN-Busverh&ltnissen und einzelnen Tasks 

eo H.l, 11.2, 11.3, etc. der Applikationssoftware unterein- 
ander. 

Da eine splche Warteschlange bezuglich eines aktuel- 
len Sendeaufrufs seitens der Applikationssoftware we- 
gen ihrer biisbelegungsabhangig asynchronen Abarbei- 
65 tung eine gewisse mittlere Mindestdurchsatzverz6ge- 
rung fur Sendeanforderungen involviert, ist f(ir beson- 
ders dringende Botschaften eine Erweiterung der 
Transmit-Funktion vorzusehen, namlich eine : 
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g. Bevorzugte Behandlung von auszusendenden Daten 

Ein bevorzugter Sofortversand eines Kommunika- 
tionsobjekts, welches in die Kommunikationswartesch- 
lange geladen wurde, ist durch den einfachen Aufruf 
TransmitFast (Zeiger auf Sende-Kommunikationsob- 
jekt) 

moglich. Dieser Treiberaufruf bewirkt, da8 das bezoge- 
ne Kommunikationsobjekt bei bereits wartenden Sen- 
deauftragen in den untersten Warteplatz in der War- 
teschlange geschrieben und wartende Auftrage somit 
urn einen Platz holier geschoben werden, von wo aus 
das Kommunikationsobjekt somit mit dem nachsten In- 
terrupt sogieich in das Sende-Bufferregister des CAN- 
Chip transferiert wird. 

Die bereits erwahnte Sendeabbruchsfunktion 
Cancel (Zeiger auf Sende-Kommunikationsobjekt) 
bewirkt LZ. mit der Sendewarteschlange die Loschung 
eines in der Warteschlange oder bereits im Chip befind- 
lichen Sendeaufrufs mit der Wirkung, daB alle nach die- 
sem Aufruf in die Warteschlange eingeschriebenen Auf- 
trage in der Prioritat urn eineri Platz nach oben (bzw. 
nach unten in der in Fig. 4 gewahlten Symboldarstellung 
der Warteschlange als FIFO-Register) rticken, von wo 
aiis sie dann um. einen Interrupt-Schritt frtiher abgear- 
beitet werden. , 

Diese Funktion erlaubt also z. B., eine bereits fur den 
Versand in die Warteschlange geladene Nachricht, die 
z. B. wegen hoher Busbeiastung aber noch nicht ver- 
sandt werden konnte und deshalb schon unaktuell ge- 
worden ist und durch eine aktuellere ersetzt werden 
sollte, unwirksam zu machen; mitt els der TransmitFast- 
Funktion kann dann die aktuell verfugbare Nachricht 
bevorzugt versandt werden (Priority- Boost). 

Im Treiber-Modul konnen noch Standby-Funktionen 
realisiert werden, so z. B.: 

h. Power Down 

Mittels des Aufrufs 
PowerDown() 

kann der CAN-Chip generell bzw. in Abhangigkeit von 
einem Argument in den stromsparenden St andby- Mo- 
dus gebracht werden. 

i. Wake Up 

Die Funktion 
WakeUpO 

wird vpm Programmierer. der Applikationssoftware 
selbst geschrieben und vom Treiber-Modul nach einem 
entsprechenden Wake-Up-Interrupt des CAN-Chip 
aufgerufen. 

Es ist insoweit ersichtlich, daB das erfindungsgemaBe 
Verfahren der Programmcodeerzeugung zur Program- 
mierung des ROMs eines busfahigen, sich auf wenig- 
stens einen Mikrorechner sttitzenden ICfz-Steuergera- 
tes zum einen zu einer erheblichen Straffung des Appli- 
kationsprogrammes und — sofern jeweils alle Steuerge- 
rate am Bus nur die zentral ausgetesteten Funktionen 
entsprechender Treiber-Module riutzen — zu einer Ef- 
fektivierung der Kommunikation im Netz ftihrt 

Fig. 6 veranschaulicht noch, wie eine Vielzahl yon 
verfahrensgemaB programmierten Steuergeraten 4A, 
4B, 4C, etc., die mit ganziich verschiedenen CAN- Chips 
1 A, IB, 1C, etc. ausgerustet sein kdnnen, uber den Bus 2 
miteinander gekoppelt werden; es ist hierbei der Son- 
derfall veranschaulicht, bei dem ein besonderes Kom- 



munikations-Modul 13 entfallt, indem die entsprechen- 
den Routinen jeweils in der geratespezif ischen Applika- 
tionssoftware 11A, 11B, 11C, etc. integriert sind. 
Dabei stellen entsprechende Treiber-Module 10A, 

5 10B, 10C, etc. teils direkt, teils uber Teile 12A, 12B, 12C, 
etc. einer ubergeordneten Netzwerkmanagement-Soft- 
ware die Verbindung unter den jeweiligen Applika- 
tionsprogrammen 11A, 11B, 11C, eta in den verschiede- 
nen Steuergeraten 4A, 4B, 4C, etc. her. 

io Es ist weiter ersichtlich, daB die schraffiert angelegten 
Teile ein virtuell einheitliches Informationssystem, d. h. 
eine virtuelle Funktionseinheit, bilden, welche/s auf- 
grund der in alien Steuergeraten verteiit untergebrach- 
ten Netzwerkmanagement-Software sowohl in Rich- 

15 tung der jeweiligen Applikationssoftware als auch in 
Richtung des Busses 2 identische Funktionalitat fiir alle 
Steuergerate 4A, 4B, 4Q eta bietet, sofern diese nur mit 
CAN-Chips gleicher Protokollnutzungsbreite ausge- 
stattetsind. 

20 Ferner ist ersichtlich, daB bei Verwendung des erfin- 
dungsgemaBen Verfahrens zur Programmierung busfa- 
higer eiektronischer Steuergerate in einem Kraftfahr- 
zeug sowohl fiir die Herstellung als auch das Austesten 
unterschiedlichster Applikationssoftware 11 A, 11B, 11C, 

25 etc. fOr die einzelnen Steuergerate 4A, 4B, 4C, etc. — 
unabhangig von dem bzw. den geratespezifisch einge- 
setztenCAN-Chip/s — identische Bedingungen vorgeb- 
bar und nutzbar sind, woraus erhebliche Zeit- und Ko- 
steneinsparungen und Sicherheitsgewinne resultieren. 

30 SchiieBlich ist ersichtlich, daB sich im Zuge der An- 
wendung des erfindungsgemaB fortgebildeten Verfah- 
rens die Realisierung des in Fig. 6 veranschaulichten 
Informationsubertragungssystems im Sinne einer virtu- 

. \ ellen Einheit praktisch von selbst ergibt Das Informa- 

35 tionsObertragungssystem wird von den schraffierten 
Teilen gebildet. Hierfiir werden also Netzwerkmanage- 
ment-Module 12A, 12B, 12C, etc. vorgesehen, die einer- 
seitsmit den jeweiligen Treiber-Modulen 10A, 10B, 10C, 
etc. und andererseits Uber ebenfalls einheitliche Kom- 

40 munikations-Schnittstellen 19A, 19B, 19C etc. mit der 
jeweiligen Applikationssoftware 11 A, 11B, HQ eta 
kommunikationsf ahig sind. 

In der Praxis ergibt sich diese Wirkstruktur durch 
einfaches Beilinken von in analoger Weise zentral aus- 

45 ge teste ten Netzwerkmanagement-Modulen 12A, 12B, 
oder 12C zusammen mit dem jeweils CAN-Chip-spezifi- 
schen Treiber-Modul 10A, 10B oder 10C zur jeweiligen 
Applikationssoftware 11 A, 11B, 11C in einer Netzwerk- 
fehler somit weitgehend ausschlieBenden Weise. 

50 

PatentansprUche 

1. Verfahren zur Programmierung eines busfahigen 
elektronischen Kfz-Steuergerates, welches zur 

55 . Realisierung seiner Steuerfunktion mit wenigstens 
einem Mikrorechner (und) mit ROM und RAM zur 
Aufnahme bzw. Abwicklung der fiir die Steuer- 
funktion erforderlichen Applikationssoftware und 
des weiteren mit wenigstens einem Bus-Protokoll- 

60 chip ausgerustet ist, und wobei die Programmie- 
rung des ROMs in einer Weise geschieht, daB be- 
sagte Applikationssoftware tiber den wenigstens 
einen Bus-Protokollchip und insoweit — im Sinne 
einer (jeweils) ersten Schnittstelle — tiber dessen/ 

65 deren spezifische Instruktions- und ICommunika- 
tionsoberflache/n mit dem Bus kommuniziert, da- 
durch gekennzeichnet 

— daB eine zweite, von dem wenigstens einen 
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Bus-Protokollchip (1; 1.1, 1.2, 13) unabhangige 
SchnittsteUe (18) im Sinne einer weiteren, uni- 
versellen Instruktions- und Kommunikations- 
oberflache def iniert wird ; 

— daB zweeks Kopplung besagter erster und 5 
zweiter Schnittstellen (17 und 18) unabhangig 
von der Applikationssoftware (11) ein auf den 
wenigstens relevanten Bus-Pro tokollchip (1; 
1.1, 1.2, 13; 1A, IB, 1C) zugeschnittenes Trei- 
ber-ModuI (10; 10'; 10A, 10B, 10C) mit den 10 
Eigenschaften eines Adapters erzeugt wird; 

— • daB bezuglich der Buskommunikation die 
steuerger&tespezifische Applikationssoftware 
(11) ausschlieBlich auf diese zweite universelle 
SchnittsteUe (18) abgestimmt und ausgerichtet 15 
und insoweit unabhangig von dem wenigstens 
einen Bus-Protokollchip erzeugt wird; 

— daB die vom Bus-Protokollchip (1; 1.1, 1.2, 
13; 1A, IB, 1C) unabhSngige Applikationssoft- 
ware, (11) und das applikationsunabhangige 20 
Treiber-Modul (10; 10A, 10B, IOC) mittels ei- 
nes 'Linkprbzesses miteinander verknupft wer- 
den, und 

— daB der als Ergebnis des Linkprozesses er- 
haltene Programmcode in besagtem ROM re- 25 
sidentabgelegt wird. 

2. Verfahren gemaB Anspruch 1, dadurch gekenn- 
zeichnet, 

— daB das Treiber-Modul (10; 10'; 10A, 10B, 
10C) in der Weise hergestellt wird, daB es nach 30 
der Verkniipfung mit der Applikationssoftwa- 
re (1 1) wenigstens folgende Funktionen leistet: 

— die Initiaiisierung der Bus-Kommuni- 
kationspfade und/oder des wenigstens ei- 
nen Bus-Protokollchip (1; 1.1, 1.2, 1.3) vor 35 
dem Beginn einer Kommunikation; 

— die Abholung von Sendedaten unter 
wenigstens einer RAM-Adresse, deren 
Ladung in ein Senderegister des. wenig- 
stens einen Bus-Protokollchip und die 40 
Veraniassung des Auslesens der Sendeda- 
ten auf den Bus; 

— die Abholung von Empfangsdaten aus 
einem Empfangsregister (21) des wenig- 
stens einen Bus-Protokollchip (1; 1.1, 1.2, 45 
13) und deren Ladung in wenigstens ei- 
nen vorbestimmten Speicherplatz (25) im 
RAM des Mikrorechners. 

3. Verfahren gemaB Anspruch 2, dadurch gekenn- 
zeichnet, - 50 

— daB das Treiber-Modul (10; 10'; 10A, 10B, 
IOC) in der. Weise hergestellt wird, daB es nach 
der VerknOpfung mit der Applikationssoftwa- 
re (11) wenigstens folgende weitere Funktio- 
nen leistet: 55 

— den Aufbau und die Verwaltung einer 
Warteschlange (20) fur Sende-Kommuni- 
kationsobjekte; 

— den bevorzugten Versand von Sende- 
Kommunikationsobjekten aus der War- 60 
teschlange (20) unter Zuweisung der je- 
weils obersten Prioritat; 

— die iridividuelle, selektive Unwirksam- 
machung von Sende-Auftragen, bevor de- 

, ren Versand erfolgt ist 65 

4. Verfahren gemaB Anspruch 1, dadurch gekenn- 
zeichnet 

— daB unabhangig von der Applikationssoft- 
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ware (1 1) und unabhangig von dem wenigstens 
einen Bus-Protokollchip (1; 1.1, 1.2, 13) noch 
. wenigstens ein weiteres Modul (12, 13), bei- 
spielsweise ein Netzwerkmanagement- Modul 
(NWM; 12), hergestellt wird, und 

- daB das wenigstens eine weitere Modul (12, 
13) mit der Applikationssoftware (11) und/ 
Oder dem Treiber-Modul (10; 10'; 10A, 10B, 
IOC) mittels eines Linkprozesses miteinander 
verknupft werden, um den im ROM des Steu- 
ergerates ablegbaren Programmcode zu er- 
halten. 

5. Verfahren gemaB Anspruch 2, dadurch gekenn- 
zeichnet, 

- daB das Treiber-Modul (10; 10'; 10A, 10B, 
10C) in der Weise hergestellt wird, daB es nach 
der VerknUpfung.mit der Applikationssoftwa- 
re (11) wenigstens folgende weitere Funktion 
leistet: 

— die Unterwerfung der Empfangsdaten 
aus einem Empfangsregister (21) des we- 
nigstens einen Bus-Protokollchip (1; 1.1, 
1.2, 13) einer Bearbeitungsfunktion und 
die Ladung der so bearbeiteten Emp- 
fangsdaten in wenigstens einen vorbe- 
stimmten Speicherplatz im RAM (16) des 
Mikrorechners des Kfz-Steuergerates. 

6. Verfahren gemaB Anspruch 2, dadurch gekenn- 
zeichnet, 

- daB das Treiber-Modul (10; 10'; 10A, 10B, 
10C) in der Weise hergestellt wird, daB es nach 
der Verkniipfung mit der Applikationssoftwa- 

; re (1 1) wenigstens folgende weitere Funktion 
leistet: 

— die Versetzung des wenigstens einen 
Bus-Protokollchip in einen stromsparen- 
den Standby-Modus. 
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